Securing sensitive user data associated with electronic transactions

ABSTRACT

A payment processor for providing a payment service includes a transaction processor to process a transaction request. An application programming interface links a merchant to the transaction processor based on an identifier. A merchant center, located between a gateway and a point of sale device of the merchant, queries a database for information associated with a buyer and the merchant based on information received from the point of sale device, to generate the transaction request based from merchant transaction data received from the point of sale device and the information associated with the buyer and the merchant received from the database, and to communicate the transaction request to the transaction processor. The transaction processor also communicates information associated with the transaction request with the merchant based on the identifier.

CROSS REFERENCE TO RELATED APPLICATION

This application is a continuation of claims priority to and the benefitof, U.S. Ser. No. 11/865,789 entitled “SYSTEM, METHOD AND COMPUTERPROGRAM PRODUCT FOR PROCESSING PAYMENTS” filed Oct. 2, 2007. The '789application claims priority to, and the benefit of, U.S. ProvisionalPatent Application Ser. No. 60/949,928, filed Jul. 16, 2007. All ofwhich are hereby incorporated by reference in their entirety.

BACKGROUND OF THE INVENTION

Field Of The Invention

The present invention generally relates to alternative payment systems,and more particularly to a system, method and computer program productfor providing registration, integration, payment processing and datacapture.

Related Art

The primary way consumers pay for items online is with the use offinancial transaction instruments (e.g., credit or debit cards or“plastic”), where a user enters card and shipping information afterhaving selected one or more items. Alternative-payment systems have beendeveloped to provide alternative means of transaction processing, bothfor the buyer and the merchant. Examples include payment services suchas Google Checkout, Bill Me Later, and eBay's PayPal.

One common aspect of many alternative payment systems is the registryfunction, which requires customers to preload information such aspersonal information and transaction account information into registrydatabases. Consumers opt-in and provide these systems with theirpersonal information as well as transaction account information.

The payment form accepted by various alternative payment systems maydiffer, however. For example, some allow the buyer to pay with a creditor debit card versus paying with a checking account.

From the buyer's perspective, one advantage of alternative paymentsystems is that only one set of buyer credentials is necessary to usemultiple commerce sites. If, for example, a buyer's credit card expiresor needs to be reissued because of fraud or some other reason, withalternative payment systems the buyer is not required to go to all ofthe commerce sites with which the buyer transacts and change any savedcard info. Instead, at worst, the buyer need only make one change.

On the merchant side, conventional alternative payment systems require amerchant to create new processes and technology each time a new paymentform is added to a merchant's infrastructure. This involves buildingentirely new linkages to accommodate the new payment solutions.Reconfiguring such an infrastructure can be costly and therefore notpractical for some businesses.

Notwithstanding the benefits provided by existing alternative paymentsystems, there is a need for a payment solution which maintains customerprivacy, provides fast, secure and convenient payment functionalitywhile reducing the integration requirements for merchants. There also isa need to maintain buyer privacy while collecting aggregate data aboutpurchases made through such payment solutions and providing consumerapproved services.

Given the foregoing, what is needed is a system, method and computerprogram product for processing payments.

BRIEF DESCRIPTION OF THE INVENTION

The present invention meets the above-identified needs by providing asystem, method and computer program product for processing payments. Inone embodiment, a system for providing a payment service includes atransaction processor configured to process a transaction request. Thesystem further includes an application programming interface operable tolink a merchant to the transaction processor based on an identifier.Also included in the system is a merchant center, located between agateway and a point of sale device of the merchant, configured to querya database for information associated with a buyer and the merchantbased on information received from the point of sale device, to generatethe transaction request based from merchant transaction data receivedfrom the point of sale device and the information associated with thebuyer and the merchant received from the database, and to communicatethe transaction request to the transaction processor. The transactionprocessor is further configured to communicate information associatedwith the transaction request with the merchant based on the identifier.

Further features and advantages of the present invention as well as thestructure and operation of various embodiments of the present inventionare described in detail below with reference to the accompanyingdrawings.

BRIEF DESCRIPTION OF THE DRAWINGS

The features and advantages of the present invention will become moreapparent from the detailed description set forth below when taken inconjunction with the drawings in which like reference numbers indicateidentical or functionally similar elements. Additionally, the left-mostdigit of a reference number identifies the drawing in which thereference number first appears.

FIG. 1 is a system diagram of an exemplary payment processing system 100in accordance with an embodiment of the present invention.

FIG. 2 is a flowchart illustrating buyer and merchant registrationprocesses in more detail, in accordance with an embodiment of thepresent invention.

FIG. 3 is a flowchart depicting an integration solution and process 300in accordance with an embodiment of the present invention.

FIG. 4 is a block diagram showing the linkage and API configuration inaccordance with an embodiment of the present invention.

FIG. 5 is a block diagram of an exemplary computer system useful forimplementing the present invention.

DETAILED DESCRIPTION

The present invention, which is directed to a system, method andcomputer program product for processing payments, is now described inmore detail herein in terms of the above exemplary credit or debit cardand banking payment processing system. This is for convenience only andis not intended to limit the application of the present invention. Infact, after reading the following description, it will be apparent toone skilled in the relevant art(s) how to implement the followinginvention in alternative embodiments involving different types ofpayment methods (e.g. electronic checking, money order, wire transfer,electronic cash, etc.)

The terms “buyer,” “user,” “end user,” “consumer,” “customer,”“participant,” and/or the plural form of these terms may be usedinterchangeably to refer to those persons or entities capable ofaccessing, using, being affected by and/or benefiting from the tool thatthe present invention provides for processing payments.

Furthermore, the terms “service establishment” (“SE”), “business,”“merchant,” “seller” and/or the plural form of these terms may be usedinterchangeably and shall mean any person, entity, distributor system,software and/or hardware that is a provider, broker and/or any otherentity in the distribution chain of goods or services. For example, amerchant may be a grocery store, a retail store, a travel agency, aservice provider, an online merchant or the like.

A “transaction account” as used herein refers to an account associatedwith an open account or a closed account system. The transaction accountmay exist in a physical or non-physical embodiment. For example, atransaction account may be distributed in non-physical embodiments suchas an account number, frequent-flyer account, telephone calling accountor the like. Furthermore, a physical embodiment of a transaction accountmay be distributed as a financial instrument.

A financial transaction instrument may be traditional plastictransaction cards, titanium-containing, or other metal-containing,transaction cards, clear and/or translucent transaction cards, foldableor otherwise unconventionally-sized transaction cards, radio-frequencyenabled transaction cards, or other types of transaction cards, such ascredit, charge, debit, pre-paid or stored-value cards, or any other likefinancial transaction instrument. A financial transaction instrument mayalso have electronic functionality provided by a network of electroniccircuitry that is printed or otherwise incorporated onto or within thetransaction instrument (and typically referred to as a “smart card”), orbe a fob having a transponder and an RFID reader.

FIG. 1 is a system diagram of an exemplary payment processing system 100in accordance with an embodiment of the present invention. Generally,system 100 includes four components: registration (A), integration (B),gateway (C), and data capture (D). These components arc arranged so asto maintain a buyer's privacy at a point-of-sale while providingconvenient purchasing and payment functionality. This arrangementfurther provides merchants with an alternative payment solutionsupported by gateway linkages to multiple types of transactionprocessors used to receive payments and leveraging any existinginfrastructure.

The registration component (A) of system 100 includes a buyer interface101, such as a home computer, a mobile phone, or other device connectedto a network such as an e-commerce network on the Internet. Prior tocompleting a transaction, a buyer registers with the provider of thesystem 100 by entering registration information as depicted in block104. This process can take place, for example, on a merchant's websitejust before the buyer checks out. Alternatively, the buyer canpreregister directly with the provider. Block 104 represents anexemplary buyer registration process for registering buyers andmerchants with either an alternate payment solution (“APS”) and/orcheckout (“CO”) website provider to execute transactions with merchants.This registration information is stored in a database referred to asdata warehouse 105. Alternatively, as described below with respect FIG.5, registration information may be stored in a separate database (notshown).

Before being provided access to system 100, a merchant must beregistered. Particularly, a merchant registers with the provider of theAPS or CO as shown in block 106.

A merchant that is not registered with a provider or does not have amerchant acquiring account with a transaction processor 124 providesinformation such as federal tax identifier, merchant name, address, andthe like, through an online merchant sign up engine 110. An example of asign up registration process is American Express's Want-to-Honor (“WTH”)registration processing system. A merchant can also apply for additionaltransaction plans (i.e., banking options, credit card issuers, and thelike) through the online merchant sign up engine 110.

Once registered with a transaction processor 124, such as a credit ordebit card company, bank or other merchant financial transactioninstrument acquirer (e.g., a credit or debit card company), the merchantis provided with a virtual point-of-sale (“POS”) terminal and a merchantand terminal ID (“MID”). When transacting, the merchant provides thealternative payment system provider with its MID information which, inturn, is received and validated by a MID validation engine 108.

The integration component (B) of system 100 takes the virtual POS andintegrates it into the processing components of a merchant's website.This can be implemented by installing application programming interfaces(“APIs”) into the merchant's website infrastructure. These APIs allowthe relevant financial transaction instrument information of the buyerand transaction information from the merchant (e.g., from the merchant'spoint of sale device) to be routed to the transaction processor 124 viaa merchant center 120 and gateway 122 without the merchant obtainingaccess during a transaction to the buyer's information such as personalor financial transaction account information.

More particularly, after merchant 102 registers, integration engine 112installs the APIs to provide links (also referred to sometimes as“feeds”) to one or more transaction processors 124 (e.g., acquirersystems). Each link supplies the information necessary to supply atransaction processor 124 with a full set of transaction informationnecessary to complete a transaction.

Application engine 114 provides online application forms to be filledout by merchants to integrate them with new transaction paymentservices. Other types of information collecting methods can be used. Forexample, industry wide standard data files can be imported into forms(e.g., using Extensible Markup Language or “XML”), or downloaded oruploaded, as the case may be, directly into data warehouse 105. Ineither case, the merchant registration data is stored in data warehouse105, which is a secure database inaccessible from the transactionprocessor 124. As shown in FIG. 1, data warehouse 105 is also incommunication with an aggregator 107 a. Aggregator 107 a may be athird-party which submits transactions for payment to a transactionprocessor 124 on behalf of other merchants who may or may not havedirect relationships with merchant acquirers on the network.

The gateway component (C) is a front-end software application thatenables financial data to be routed to the respective transactionprocessors. More particularly, gateway 122 is a server basedinfrastructure containing software which inserts the buyer and sellerdetails into a payment processing network's authorizationinfrastructure, such as credit/debit or bank acquirer transactionprocessor(s) 124.

As the new transaction processors are added to system 100, additionalconnections are added to system 100 to connect the transactionprocessors to gateway 122. This is accomplished by configuring thesoftware of the gateway to handle the data structures of the newtransaction processor and by adding additional links (sometimes referredto as “pipes”) using conventional leased telecommunications lines orinternet-based telecommunication protocols.

Once the merchant has registered and been integrated into system 100, abuyer can then shop at a merchant website through its interface 116.This is accomplished, for example, by connecting to the merchant'swebsite and logging in with a login and password if pre-registered. Ifnot pre-registered the buyer may shop and proceed to registration whenready to complete the transaction, it should be understood that otherauthentication techniques may be utilized instead of a login andpassword, such as smartcard, biometric, RFID or other form ofauthentication device or method. Once authenticated, the buyer istransferred to merchant's website 118 which has been enabled to acceptthe payment solution described herein.

After shopping, the buyer finalizes the transaction by selecting, forexample, a “checkout” button (not shown). The checkout page is hostedoff of the merchant's website hosted by enabled engine 118. In otherwords, when the buyer initiates a checkout process, the buyer is thenpassed from the merchant's website to another, secure website.Alternatively, the checkout page can be hosted by the provider of system100.

Upon submission of a transaction, the merchant transmits anauthorization request to the transaction processor 124 via the enabledmerchant engine 118. Logic within merchant center 120 queries the datawarehouse 105 for buyer and merchant details and then generates therequired authorization request and submission message (for simplicitycollectively called “a transaction request”) for insertion into gateway122. The details merchant center 120 obtains from data warehouse 105include informatinon associated with the buyer such as buyer transactionaccount information, name, address and the like, and informationassociated with the merchant such as acquirer identifier and otherinformation required by a particular transaction processor.

The gateway 122, in turn, submits the message to transaction processor124. In response, the transaction processor 124 provides a response tothe authorization request (e.g., approval or decline) to the merchant.The merchant is provided a reference number corresponding to atransaction so that it can track and further process the transaction,but the merchant is not provided the buyer's transaction accountinformation, thereby keeping the buyer's financial transaction accountinformation private during the transaction processing.

The particular codes that are exchanged between the enabled merchantengine 118 and merchant center 120 are messages used betweenconventional transaction processing systems and merchants. Other newforms of transaction processing messages may be developed and used inaddition to, or in place of the convention transaction messages sincethe payment solution described herein moves the servicing responsibilityto the transaction processor 124. Similarly, reconciliation may be madebetween transaction processor 124 and the merchant 102 withoutadditional configuration by the merchant.

Data warehouse 105 stores the purchase information (i.e., line itemdata), such as SKU data, quantity, the buyer's transaction accountnumber, shipping information, and the like, received from merchantcenter 120. In addition, data warehouse may store buyer information,such as profiles, transaction account information, ship to information,and the like. Other information, such as websites visited, and the like,may also be stored in data warehouse 105.

Data capture component (D) 107 is an optional component which providesthe ability for third parties (or the provider of system 100 itself) tocollect information about transactions and buyers. The data can be usedto enhance the customer's search and shopping experience and otherapplications per the permission granted by, for example, a user opt-in.

As explained above, data capture component (P) 107 may include anaggregator engine 107 a which can submit transactions for payment to atransaction processor on behalf of other merchants who may or may nothave direct relationships with merchant acquirers on the network.Aggregator 107 a can also compile and distill the information itreceives. Particularly, aggregator engine 107 a allows a provider orthird party to use transaction information for statistical or marketingpurposes. Aggregator 107 a also can be configured to feed information toan advertising search engine 107 b, which may further analyze the datato provide custom advertising or marketing.

As described above, from the data warehouse 105, the buyer's data ismoved to the merchant center 120. Merchant center 120 combines themerchant and buyer data to create a full transaction data set and inturn communicates the financial transaction data to a gateway 1220.Thus, the transaction is isolated from the merchant's website and isinstead concatenated at the merchant center 120. Similarly, the personalinformation of the buyer can be isolated from the data capture component107.

As explained above, gateway 122 routes the transaction data to theappropriate transaction processor 124, such as a bankcard processor orcredit card (e.g. American Express or “AXP”) issuer. Since the merchantis not provided the buyer's transaction account information during atransaction, the buyer's transaction account information is keptprivate.

FIG. 2 is a flowchart illustrating buyer and seller registrationprocesses 200 in more detail. In one embodiment, the buyer registrationprocess operates in a conventional business-as-usual (“BAU”) manner suchthat the user transaction experience is similar to past transactionexperiences. Buyer registration is performed by an operator enteringbuyer registration information through a buyer interface 101. As thebuyer inputs data through buyer interface 101, the data is fed toregistration engine 104. Registration engine 104, in turn, performs thesteps necessary to register the buyer. Once registration engine 104 hascompleted registering the buyer, the buyer's spending limit isdetermined by a buyer validation engine 202. Buyer validation engine 202performs an authorization process with the transaction processor (i.e.,bank or credit card issuer) in order to determine an amount the buyer isauthorized to spend. Once registered and validated the buyer is taggedas an enabled buyer as shown in block 204.

Merchant registration is performed by an operator entering sellerregistration information through establishment (i.e., seller) interface102. In one embodiment, the seller registration process requiresmerchants to input additional information initially by usingconventional service establishment or merchant identifier numbers to vetplastic-accepting merchants and facilitate registration. By registeringup front, service establishments which are not registered to acceptplastic can sign up for plastic acceptance through sign-up channels suchas American Expresses want-to-honor (“WTH”) or bankcard applications. Asregistration information is entered, it is fed to registration engine106 which feeds the data to either plastic (e.g., credit/debit card)acceptance engine 206 or non plastic (i.e., non credit card) acceptance.If the merchant wishes to accept plastic, then the service establishmentis validated using service establishment or merchant identifiervalidation engine 210. Once the service establishment validation engine210 has completed validating the service establishment, the serviceestablishment's website is integrated using site integration engine 212.Once the service establishment is validated and its website integratedusing application program interfaces (“APIs”), then the serviceestablishment is an enabled seller as shown in block 214.

If the merchant does not accept plastic (block 208), then the serviceestablishment can choose between various payment types to apply forusing acceptance application engine 216. The transaction processor 218(e.g., credit, debit card, or bankcard acquirer) determines whether theservice establishment can establish a transaction account. If theservice establishment is not accepted by the transaction processor 218,then the application is rejected, as shown in block 222. If the serviceestablishment is accepted, then at block 220 the service establishmentis considered registered and the process continues at block 210, asdescribe above.

Advantageously, the above described registration processes maintain userprivacy at a point of sale. The service establishment is not providedwith the buyer or sellers personal profile data since that data isstored in data warehouse 105.

FIG. 3 is a flowchart depicting an integration process 300 in accordancewith an embodiment of the present invention. Process 300 begins after aservice establishment has been registered as shown in block 302. Onceregistered, the service establishment has one of three alternativeintegration procedures to follow. In the embodiment depicted in FIG. 3,the integration procedure followed by the service establishment dependson the size of the service establishment. For small sellers with basicpayment needs, the service establishment can be integrated with aconventional click and buy engine 304, which links to a hosted paymentwebsite 306. A hosted payment website allows a third party to processpayments on its payment page as shown in block 308. For small to mediumsized sellers having a conventional shopping cart, the serviceestablishment integrates using a standard shopping card pre-integrationengine 310, which involves downloading pre-integrated applicationprogramming interfaces (APIs), as shown in block 312. Once integrated,at block 314, the registered service establishment provides a link fromthe checkout to the web front end. For large sellers with custome-commerce infrastructures, a custom integration can be performed asshown in block 316. Once the service establishment is integrated, thenan alternative payment solution is deployed using a software developmentkit (“SDK”) and associated libraries as shown at block 318. Once thepayment solution has been deployed, a service establishment can join,integrate and test their systems, as shown in block 320.

FIG. 4 is a block diagram showing the linkages and API configuration inaccordance with an embodiment of the present invention. As shown in FIG.4, transaction processors 124 (e.g., acquirer processors) are linked tomerchant systems 404 by acquirer/processor links 402. As describedabove, Gateway 122 is a front-end software application that enablesfinancial data to be routed to the respective transaction processors124. As shown, each merchant system 404 maintains its own transactionprocessor links 402.

A payment solution engine 410 integrates with the web front end of theenabled merchant website 406 using payment solution tools and APIs 408.Payment solution tools and APIs 408 also supply the software and linksused to leverage gateway 122 to route transactions to the merchants. Byincorporating tools and APIs 408 between the gateway and paymentsolution (blocks 122, 410, respectively) and merchant systems andwebsites (blocks 404, 408, respectively), the gateway 122 is leveragedto route transactions to the merchants existing transaction processor124 rather than require the merchants to create new links. A registryengine 410 feeds the payment solution engine 410 buyer and merchantregistration information. In addition, as explained above, datawarehouse 105, which may be one or more databases, captures transactiondetails.

The present invention (i.e., systems and processes 100, 200, 300 and400) or any part(s) or function(s) thereof) may be implemented usinghardware, software or a combination thereof and may be implemented inone or more computer systems or other processing systems. However, themanipulations performed by the present invention were often referred toin terms, such as logging in or filling out a form, which are commonlyassociated with mental operations performed by a human operator. No suchcapability of a human operator is necessary, or desirable in most cases,in any of the operations described herein which form part of the presentinvention. Rather, the operations are machine operations. Usefulmachines for performing the operation of the present invention includegeneral purpose digital computers or similar devices.

In fact, in one embodiment, the invention is directed toward one or morecomputer systems capable of carrying out the functionality describedherein. An example of a computer system 500 is shown in FIG. 5.

The computer system 500 includes one or more processors, such asprocessor 504. The processor 504 is connected to a communicationinfrastructure 506 (e.g., a communications bus, cross-over bar, ornetwork). Various software embodiments are described in terms of thisexemplary computer system. After reading this description, it willbecome apparent to a person skilled in the relevant art(s) how toimplement the invention using other computer systems and/orarchitectures.

Computer system 500 can include a display interface 502 that forwardsgraphics, text, and other data from the communication infrastructure 506(or from a frame buffer not shown) for display on the display unit 530.

Computer system 500 also includes a main memory 508, preferably randomaccess memory (RAM), and may also include a secondary memory 510. Thesecondary memory 510 may include, for example, a hard disk drive 512and/or a removable storage drive 514, representing a floppy disk drive,a magnetic tape drive, an optical disk drive, etc. The removable storagedrive 514 reads from and/or writes to a removable storage unit 518 in awell known manner. Removable storage unit 518 represents a floppy disk,magnetic tape, optical disk, etc., which is read by and written to byremovable storage drive 514. As will be appreciated, the removablestorage unit 518 includes a computer usable storage medium having storedtherein computer software and/or data.

In alternative embodiments, secondary memory 510 may include othersimilar devices for allowing computer programs or other instructions tobe loaded into computer system 500. Such devices may include, forexample, a removable storage unit 522 and an interface 520. Examples ofsuch may include a program cartridge and cartridge interface (such asthat found in video game devices), a removable memory chip (such as anerasable programmable read only memory (EPROM), or programmable readonly memory (PROM)) and associated socket, and other removable storageunits 522 and interfaces 520, which allow software and data to betransferred from the removable storage unit 522 to computer system 500.

Computer system 500 may also include a communications interface 524.Communications interface 524 allows software and data to be transferredbetween computer system 500 and external devices. Examples ofcommunications interface 524 may include a modem, a network interface(such as an Ethernet card), a communications port, a Personal ComputerMemory Card International Association (PCMCIA) slot and card, etc.Software and data transferred via communications interface 524 are inthe form of signals 528 which may be electronic, electromagnetic,optical or other signals capable of being received by communicationsinterface 524. These signals 528 are provided to communicationsinterface 524 via a communications path (e.g., channel) 526. Thischannel 526 carries signals 528 and may be implemented using wire orcable, fiber optics, a telephone line, a cellular link, a radiofrequency (RF) link and other communications channels.

In this document, the terms “computer program medium” and “computerusable medium” are used to generally refer to media such as removablestorage drive 514, a hard disk installed in hard disk drive 512, andsignals 528. These computer program products provide software tocomputer system 500. The invention is directed to such computer programproducts.

Computer programs (also referred to as computer control logic) arestored in main memory 508 and/or secondary memory 510. Computer programsmay also be received via communications interface 524. Such computerprograms, when executed, enable the computer system 500 to perform thefeatures of the present invention, as discussed herein. In particular,the computer programs, when executed, enable the processor 504 toperform the features of the present invention. Accordingly, suchcomputer programs represent controllers of the computer system 500.

In an embodiment where the invention is implemented using software, thesoftware may be stored in a computer program product and loaded intocomputer system 500 using removable storage drive 514, hard drive 512 orcommunications interface 524. The control logic (software), whenexecuted by the processor 504, causes the processor 504 to perform thefunctions of the invention as described herein.

In another embodiment, the invention is implemented primarily inhardware using, for example, hardware components such as applicationspecific integrated circuits (ASICs). Implementation of the hardwarestate machine so as to perform the functions described herein will beapparent to persons skilled in the relevant art(s).

In yet another embodiment, the invention is implemented using acombination of both hardware and software.

While various embodiments of the present invention have been describedabove, it should be understood that they have been presented by way ofexample, and not limitation. It will be apparent to persons skilled inthe relevant art(s) that various changes in form and detail can be madetherein without departing from the spirit and scope of the presentinvention. Thus, the present invention should not be limited by any ofthe above described exemplary embodiments, but should be defined only inaccordance with the following claims and their equivalents,

In addition, it should be understood that the figures and screen shotsillustrated in the attachments, which highlight the functionality andadvantages of the present invention, are presented for example purposesonly. The architecture of the present invention is sufficiently flexibleand configurable, such that it may be utilized (and navigated) in waysother than that shown in the accompanying figures.

Further, the purpose of the foregoing Abstract is to enable the U.S.Patent and Trademark Office and the public generally, and especially thescientists, engineers and practitioners in the art who are not familiarwith patent or legal terms or phraseology, to determine quickly from acursory inspection the nature and essence of the technical disclosure ofthe application. The Abstract is not intended to be limiting as to thescope of the present invention in any way. It is also to be understoodthat the steps and processes recited in the claims need not be performedin the order presented.

1-20. (canceled)
 21. A computing system, comprising: communicationcircuitry; and one or more processing elements configured to: receive,from a first entity via the communication circuitry, a transactionrequest that includes first information identifying a user, wherein thefirst information is entered via a virtual point-of-sale device that isintegrated into a website of the first entity; retrieve, from anelectronic database, second information that identifies an account ofthe user that is to be used for the transaction, wherein the transactionrequest does not include the second information and wherein theelectronic database is not accessible to the first entity; transmit arequest, via a gateway component, wherein the request includes both thefirst and second information, wherein the gateway component isconfigured to route transactions to a processor network based on thesecond information; receive an authorization response via the gatewaycomponent; and transmit the authorization response to the first entity.22. The computing system of claim 21, wherein the one or more processingelements are further configured to register the user and store thesecond information in the electronic database prior to receiving thetransaction request.
 23. The computing system of claim 21, wherein theone or more processing elements are further configured to retrieve thirdinformation for the first entity from the electronic database andinclude the third information in the request.
 24. The computing systemof claim 23, wherein the third information is not accessible to theuser.
 25. The computing system of claim 21, wherein the one or moreprocessing elements execute instructions of an application programminginterface (API) to include the second information in the request. 26.The computing system of claim 21, wherein the one or more processingelements are further configured to transmit, to the first entity,digital information that encodes the virtual point-of-sale device. 27.The computing system of claim 21, wherein the one or more processingelements are configured to transmit an identifier for the request toboth the first entity and the processor network.
 28. A method,comprising: receiving, by a merchant center system from a first entity,a transaction request that includes first information identifying auser, wherein the first information is entered via a virtualpoint-of-sale device that is integrated into a website of the firstentity; retrieving, by the merchant center system from an electronicdatabase, second information that identifies an account of the user thatis to be used for the transaction, wherein the transaction request doesnot include the second information and wherein the electronic databaseis not accessible to the first entity; transmitting a request from themerchant center system via a gateway component, wherein the requestincludes both the first and second information, wherein the gatewaycomponent is configured to route transactions to an processor networkbased on the second information; receiving, by the merchant centersystem, an authorization response via the gateway component; andtransmitting, by the merchant center system, the authorization responseto the first entity.
 29. The method of claim 28, wherein the transactionrequest is routed to the merchant center system based on registration ofthe first entity with the merchant center system.
 30. The method ofclaim 28, further comprising: prior to receiving the transactionrequest: registering the user; receiving the second information from theuser; and storing the second information in the electronic database. 31.The method of claim 28, further comprising: retrieving third informationfor the first entity from the electronic database and including thethird information in the request.
 32. The method of claim 31, whereinthe third information is not accessible to the user.
 33. The method ofclaim 28, wherein the second information is included in the requestaccording to an application programming interface (API).
 34. The methodof claim 28, further comprising: transmitting digital information thatencodes the virtual point-of-sale device to the first entity forintegration with the website of the first entity.
 35. The method ofclaim 28, further comprising: including an identifier in the request andtransmitting the identifier to the first entity.
 36. A non-transitorycomputer-readable medium having instructions stored thereon that areexecutable by a computing device to perform operations comprising:receiving, from a first entity, a transaction request that includesfirst information identifying a user, wherein the first information isentered via a virtual point-of-sale device that is integrated into awebsite of the first entity; retrieving, from a database, secondinformation that identifies an account of the user that is to be usedfor the transaction, wherein the transaction request does not includethe second information and wherein the database is not accessible to thefirst entity; transmitting a request via a gateway component, whereinthe request includes both the first and second information, wherein thegateway component is configured to route transactions to an processornetwork based on the second information; receiving an authorizationresponse via the gateway component; and transmitting the authorizationresponse to the first entity.
 37. The non-transitory computer-readablemedium of claim 36, wherein the operations further comprise registeringthe user and storing the second information in the database.
 38. Thenon-transitory computer-readable medium of claim 36, wherein theoperations further comprise retrieving third information for the firstentity from the database and including the third information in therequest.
 39. The non-transitory computer-readable medium of claim 36,wherein the operations further comprise transmitting digital informationthat encodes the virtual point-of-sale device to the first entity forintegration with the website of the first entity.
 40. The non-transitorycomputer-readable medium of claim 36, wherein the operations furthercomprise including an identifier in the request and transmitting theidentifier to the first entity.